一開始收到業務團隊需求的時候，我們其實以為這個工具的scope不會太大。

畢竟它一開始只是要協助業務團隊做提案會議的品質評量，看起來就是把流程串起來，讓錄音、逐字稿、評分和報告可以自動化地完成。

但實際開始開發、上線，使用者慢慢增加之後，事情就開始跟原本想的越來越不同。使用者不再只有單一身份，而開始出現不同的角色和權限；會議素材數量越來越多，除了原始錄音錄影檔之外，還會產生逐字稿、評分報告等衍生資料；使用者增加之後，系統需要處理的資料數量和型態也隨之增加，原本沒有特別需要考慮的處理速度和系統穩定性，開始變成實際使用時會遇到的問題。

換句話說，這個工具的scope在開發過程中不斷擴張，而我們的開發方式也不是標準的產品開發流程。我們沒有一開始就把完整的roadmap、所有使用情境和未來的系統需求都全面定義好，很多時候都是先遇到實際問題，再往下補功能。使用者提出新的需求，我們就討論這個需求應該怎麼做；開發過程中發現原本的設計不夠，我們再調整。這種邊做邊長大的方式，在前期沒有太大的問題，但到了中期，我開始逐漸感覺到瓶頸。最常發生的情況就是「修A壞B」。我可能只是想優化一個功能，結果另一個原本正常運作的地方突然出現問題，接下來就需要再花時間讓AI回頭檢查，到底是哪一個修改造成了副作用，時常要來回幾次，才能找到真正的問題根因。我逐漸發現，這些問題很多時候並不是單純的bug，而是原本的系統設計開始不足以支應後來不斷增加的功能、使用者和資料量。

不順的狀況持續了幾週，到後來卡關到一個程度，我們決定先停下來，不再繼續一個功能、一個bug地單點處理，而是重新全面盤點一次整個系統。我們把目前實際需要承接的使用者數量、資料量、使用者角色和權限分層、後台管理機制，以及目前已經存在的功能重新看了一遍，同時也把時間拉得更遠，思考這套系統接下來希望往哪個方向發展，以及哪些地方可能會繼續擴張。我們第一次把系統定位、目標、預期達到的效益，以及一些重要的設計原則整理下來，把這些內容寫成Markdown文件，放進GitHub project裡，作為後續開發時可依循的專案脈絡和 guideline。

以前我和AI協作開發時通常都是丟出一個局部的需求，例如：「幫我增加xx功能」、「幫我調整這個頁面」，AI確實可以把這些事情做出來，但如果它不知道這個系統為什麼存在、使用者是誰、整個系統的框架，它很容易只針對眼前的問題尋求單一的解法，而這解法可能在整個系統運行裡並非最佳解，甚至會和後續許多需求有所衝突。

有了markdown文件提供專案脈絡之後，AI能夠在協作時先理解整個專案目標、目前系統架構、使用情境和設計原則，再開始思考如何做修改和優化。Markdown文件並非把每一個功能如何實作寫死，而是大方向說明這個系統要解決什麼問題、目標是什麼、有哪些使用情境、需要考慮的限制，以及我們希望系統往哪個方向走。我覺得markdown的重點反而是不要定義得太細，因為系統還在快速演進，今天寫得很詳細的執行細節，過一陣子可能就被新的需求推翻。如果一開始就把所有解法寫死，反而會限制後面的發展空間。因此，Markdown比較像是張地圖：它需要把目的地、為什麼要去那裡，以及不能違逆的基本原則和限制說清楚，但不需要規定非得要走哪一條路線不可。因為實際上可以走的路可能不只一條。

在沒有太多技術背景的情況下，我自己能想到的解法可能就那幾種。當我把問題和目標告訴AI之後，它有時候反而會提出一些我原本無法想像到的做法。因為知識背景有限而造成的想像侷限，多虧和AI協作而可以補足，幫我探索還有哪些未知的可能性。所以在這過程中也學到的是，不要一開始就急著告訴AI要用什麼方法去做，而是先把問題、目標、限制和整體脈絡定義清楚，再讓它在這個框架裡提出解法。

最終，我需要做的最重要的事其實是定義清楚：這個系統到底要解決什麼問題，以及我們希望它的願景是什麼。Vibe coding能不能有好的產出，最關鍵可能在於我能不能把專案的目標和框架想清楚。